home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1995 April / Internet Tools.iso / infoserv / www / cern / dev / www-talk.9301-9306.Z / www-talk.9301-9306 / text1493.txt < prev    next >
Encoding:
Text File  |  1995-04-24  |  2.8 KB  |  59 lines
  1. > >Servers are not _that_ easy to write.  They are if you're running UNIX
  2. > >and you have either inetd.conf privileges or know how to do sockets.
  3. > >Who knows what you'd have to do under VMS or MVS and you just can't
  4. > >do them under MS-DOS.  On the other hand, writing a program which
  5. > >dumps some HTML to a file is easy and possible under all systems.
  6. > >It's very similar to adding to a server, but anybody, not just the
  7. > >server administrator can do it and they can share with other non-privileged
  8. > >users.
  9.  
  10. As a side note, xinetd -- recently posted to comp.sources.unix
  11. -- allows users to run a (turbocharged version of) inetd
  12. without root privileges.
  13.  
  14. > >Even if you can easily run a server, you've got some security problems
  15. > >to deal with.  Having a browser that will execute code (or URLs, whatever)
  16. > >from documents is a little scary; having a server that anyone can
  17. > >connect to execute code is really scary.  With the browser executing
  18. > >code you leverage off the normal system authentication.  With a server,
  19. > >you have to re-invent that.  Sure, these features are coming and
  20. > >that's good; but you're building up an awful lot of stuff to solve
  21. > >a simple problem.
  22. > 
  23. > Servers can run without privilige; ours runs as id "daemon" and
  24. > doesn't have the priv to do much other than dequeue other people's
  25. > print jobs.  Surely webmasters don't run their HTTP server as root?
  26. > 
  27. > Browsers, on the other hand, have to run as users and are thus capable
  28. > of harming their users; I find using "normal system authentication"
  29. > (as it exists on most machines) to run code in this kind of situation
  30. > highly undesirable.
  31.  
  32. Having browsers execute code is *very* scary.  Servers generally run
  33. (or should run -- no reason not to) as userid 'nobody', and as such
  34. can cause practically no damage to anything.  In any case, server
  35. writers have much more knowledge about what's going to happen and what
  36. could happen while writing a server than client users do while just
  37. randomly clicking hyperlinks.  I don't see as there's any reason to
  38. think that client-side execution is safer.
  39.  
  40. > >Well, if you want to add features you have a choice.  Either make it
  41. > >harder for the browser writers or make it harder for the server writers.
  42. > >I maintain that the exec: URL scheme makes it a little harder for
  43. > >the browser writers but is a boon for server writers since it truly
  44. > >makes it easy to write a server (just like the simple inetd scripts,
  45. > >but you don't need privilege).
  46. > 
  47. > Except that what has been written isn't a server at all, it's just a
  48. > program.  It doens't provide a service to anyone except the person (or
  49. > small group of people) who have examined it, decided it safe, and
  50. > placed it on their list of commands for which exec:ing is permissible.
  51. > (unless this procedure is not used, in which case it's a security hole
  52. > you could drive an aircraft carrier through.)
  53.  
  54. What he said.
  55.  
  56. Marc
  57.  
  58.  
  59.